如果在ES中會不斷累積資料的index
例如紀錄每日access-log的相關index
除了資料會不斷累積之外，相比最新的資料
我們可能對於較舊的資料查詢的需求會比較低

ES提供Index lifecycle management(ILM)來幫助管理這種time series data以及data stream

• 設定特定保留期限，超出保存時間的資料會被ES去除
• 設定multiple tiers，讓處於不同時間階段的index有不同的表現特性，並且能自動轉換
• 較舊較不重要的資料，藉由不同方式維持部分查詢效能，同時不佔太多空間
  • 在遠程庫儲存snapshots
  • 使用非同步查詢

之前我們好像沒有提過data stream

• 只適用於append-only time series data

• 可以儲存跨多個index的資料，並且賦予name讓請求時能夠宣告

  • 當收到請求時會導向data stream背後的index
  • 需要對應的index template

• 適合儲存有關log等持續增長的資料

• 在data stream底下的文檔必須包含@timestamp field

  • 且必須為date或是date_nanos類型
    
    圖源：https://www.elastic.co/guide/en/elasticsearch/reference/current/data-streams.html

• 寫入一個data stream時，會優先寫入底下最新創建的index

  • 不能直接寫入其他backing index，即使直接指定該index
    
    圖源：https://www.elastic.co/guide/en/elasticsearch/reference/current/data-streams.html

ILM將index定義成5種生命週期階段

在不同階段，也有規範可以執行的操作

針對其中幾種action來進行說明

Rollover

• 當滿足特定條件時，會將目標滾動至新的index
  • 目標可以為index或是data stream
    • 條件可以為當目標達到某個大小、資料筆數或是時間
• 動作流程：
  • 達到特定條件後，將index alias滾動至新的write index
    • 如果一個index alias指向多個index，必須要有一個write index，負責寫入資料
      • 將新write index的is_write_index設為true
      • 將先前的write index的is_write_index設為false
    • 如果只指向一個index，將指向舊的index別名設定刪除，指向新的index路徑

Shrink

• 將現有的index轉入設定都一樣的新index，但是shard數量較少
  • 根據primary shard數量的因數來決定(不含本身且含1)。例如原本有8個primary shard，可以shrink成4, 2, 1
• 動作流程：
  • 建立新index，並使其狀態為_close
  • 會透過hard-links將segment file從現有index轉到新index
  • 如果不支援hard-link，會直接將所有segment轉移
  • 轉移資料後將index open
• ILMreallocate已經shrink的index，會根據你設定的allocation rules將其分配到適合的nodes上

Force Merge

• 減少shard中segment file的數量，將其進行合併
  • 可以藉此提升查詢效率
  • 減少儲存壓力
• 一般來說會自動執行，但是也能使用手動執行
• 當index進入read-only狀態時，就會對index執行
  • 因為合併後的segment可能會非常大(>5GB)
  • 所以確定index再也不寫入才執行(不會出現在hot phase)

Allocate

• 將shard移到其他node上
• index 進入另一個 phase 時，不同的 phase 能使用不同的硬體資源
  • 因此轉移到其他node(硬體主機)時，也會藉此將shard轉移到更適合的node上進行表現

Searchable Snapshot

• snapshot 是叢集的資料備份
  • 包含cluster state, data stream與index
  • 會將重複的資料刪除，節省儲存空間
  • 備份index時，會複製index的segment file並且存入snapshot repository
  • 因為segment是不會變的，所以snapshot只要複製上次儲存之後新建立的segment file
• Searchable snapshots能夠使用cost-effective方式來搜尋那些非常少訪問的資料
• cold跟frozen階段使用這種方式來降低儲存與操作成本
  • 在index進入這兩個階段時，自動將index轉換成Searchable snapshots
  • 也可以用mount snapshot API來手動對現有index執行

這邊簡單做個統整：

1. 當index達到某些標準時，我們需要將其轉換到不同階段
2. 需要藉由rollover，將source index中的資料滾動到target中
   • target可能是data stream或是index
3. 舊的index會shrink成較小shard的index，以及透過force merge的方式去優化資料
4. allocate到其他主機上，改變表現形式
5. 在進到cold跟frozen時會藉由searchable snapshots來達到最低限度的儲存方式
6. 確定資料不在需要時，將其delete

不過這不是絕對的流程，也不一定符合所有情況
只是藉由這樣的介紹希望能更了解這些機制的運作模式與應用場景

今天介紹了ES對於不同資料形式
index以及data stream的管理方式以及原理
明天會介紹相關的API使用方式

參考資料
data stream：
https://www.elastic.co/guide/en/elasticsearch/reference/current/data-streams.html
data management：
https://www.elastic.co/guide/en/elasticsearch/reference/current/data-management.html
index lifecycle：
https://www.elastic.co/guide/en/elasticsearch/reference/current/ilm-index-lifecycle.html
rollover：
https://www.elastic.co/guide/en/elasticsearch/reference/current/ilm-rollover.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-rollover-index.html
shrink：
https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-shrink-index.html
force merge：
https://www.elastic.co/guide/en/elasticsearch/reference/7.17/indices-forcemerge.html
allocate：
https://www.elastic.co/guide/en/elasticsearch/reference/current/ilm-allocate.html
snapshots：
https://www.elastic.co/guide/en/elasticsearch/reference/current/snapshot-restore.html
searchable snapshots：
https://www.elastic.co/guide/en/elasticsearch/reference/current/searchable-snapshots.html